На интересный момент обратил в своем блоге Mark Ukotic: ведь гостевая ОС Microsoft Windows Server 2019 недоступна при указании типа гостевой системы на платформе VMware vSphere:

Между тем, Windows Server 2019, вышедший еще в октябре прошлого года, полностью поддерживается в последних версиях VMware vSphere. Согласно статье KB 59222, для Windows Server 2019 нужно выбрать тип гостевой ОС Windows Server 2016 or later. Если подумать, это очень странно - ведь за прошедший с момента релиза год выходило немало апдейтов платформы VMware vSphere, хотя бы тот же vSphere 6.7 Update 3, но отдельной строчки для последней серверной платформы Microsoft в интерфейсе так и не появилось.

Однако если взглянуть на VMware Compatibility Guide и выбрать там в поле OS Family name систему Windows Server 2019, то мы увидим, что ESXi вполне ее поддерживает, начиная с версии 6.0.

Согласно политике поддержки VMware, если мы видим эту ОС в HCL, то она полностью поддерживается для работы в виртуальной машине на платформе vSphere.

То есть это чисто интерфейсная особенность, где поддержка Windows Server 2019 скрывается за окончанием пункта "or later".

Как вы знаете, на этой неделе проходит крупнейшая конференция о виртуализации в Европе - VMworld Europe 2019. О прошедших анонсах старшей ее сестры - VMworld 2019 - мы говорили вот тут.

На этой неделе мы писали о Skyline Health for vSAN, а сегодня мы расскажем еще об одной полезности - виртуальном модуле vCenter Event Broker Appliance (VEBA), который стал доступен на VMware Labs сразу после анонса.

Сервис VEBA позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That".

Также VEBA дает решения для более серьезных интеграций, таких как Slack или Pager Duty, которые можно разрабатывать отдельно, используя предоставляемые инструменты. Уже довольно давно нечто подобное сделала компания Amazon в рамках решения AWS Lambda для своей облачной инфраструктуры.

Виртуальный модуль VEBA в формате виртуальной машины можно развернуть в любом виртуальном окружении - в частном или публичном облаке на базе VMware vSphere, например, VMware Cloud on AWS или VMware Cloud on Dell-EMC.

С помощью этого инструмента программистам не нужно глубоко нырять в логику происхождения событий и понимать структуру API, к ним относящимся. За счет этого скорость разработки существенно повышается.

Скачать VMware vCenter Event Broker Appliance можно по этой ссылке.

Год назад мы писали о средствах VMware vCenter Server Appliance для резервного копирования и восстановления на уровне файлов. Эти функции появились в VMware vCSA 6.5 и были существенно доработаны в версии vCSA 6.7 (отдельный раздел Backup, запланированные резервные копии, политика хранения бэкапов, браузер файлов и т.п.).

В то же время, у пользователей VMware vCSA есть запрос на автоматизацию процесса резервного копирования средствами PowerCLI через механизм vSphere RESTful API. На блогах VMware появилась интересная статья, описывающая данный процесс, приведем ниже основные его моменты.

Взаимодействие с механизмом резервного копирования vCSA происходит через модуль CIS, который взаимодействует с компонентами инфраструктуры на низком уровне. Первым шагом как раз и является подключение к службе CIS:

Connect-CisServer -Server vcsa01.corp.local

Затем нужно найти сервис, для которого нужно сделать резервную копию:

Get-CisService -Name *backup*

Из вывода видно, что нам нужен сервис com.vmware.appliance.recovery.backup.job. Сохраняем его в переменую и передаем в Get-Member:

В выводе мы видим метод create, который позволяет создать задачу резервного копирования, а также свойство help, которое помогает сформировать входные параметры для задачи РК:

$backupJobSvc.Help.create.piece

Теперь можно заполнить поля задачи данными из нашего окружения. Параметр parts ожидает на вход тип массив, также в параметре password нужно передать специальный тип, чтобы он был принят:

$backupSpec.parts = @("common")

$backupSpec.location_type = "FTP"

$backupSpec.location = "ftp01.corp.local"

$backupSpec.location_user = "backup"

[VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSpec.location_password = "VMware1!"

$backupSpec.comment = "PowerCLI Backup Job"

После этого можно уже создавать задачу РК:

$backupJob = $backupJobSvc.create($backupSpec)

Теперь объединяем это все в один скрипт:

# Login to the CIS Service of the desired VCSA

Connect-CisServer -Server vcsa01.corp.local
# Store the Backup Job Service into a variable

  $backupJobSvc = Get-CisService -Name com.vmware.appliance.recovery.backup.job
# Create a specification based on the Help response

  $backupSpec = $backupJobSvc.Help.create.piece.CreateExample()
# Fill in each input parameter, as needed

  $backupSpec.parts = @("common")

  $backupSpec.location_type = "FTP"

  $backupSpec.location = "ftp01.corp.local"

  $backupSpec.location_user = "backup"

  [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSpec.location_password = "VMware1!"

  $backupSpec.comment = "PowerCLI Backup Job"
# Create the backup job 

  $backupJobSvc.create($backupSpec)

Чтобы создать запланированную задачу резервного копирования, надо использовать сервис com.vmware.appliance.recovery.backup.schedules. Тут нам надо задать schedule ID (это строковый параметр по вашему выбору, задается опционально) и заполнить спецификацию аналогично предыдущему сценарию.

Периодичность бэкапа задается через свойство days, которое можно оставить неустановленным (бэкап будет делаться каждый день), либо задать конкретные дни в виде массива.

Ну и, собственно сам сценарий запланированного бэкапа VMware vCSA на уровне файлов через PowerCLI:

# Store the Backup Job Service into a variable

$backupSchedSvc = Get-CisService -Name com.vmware.appliance.recovery.backup.schedules
# Create a Schedule ID specification based on the Help response

  $schedSpec = $backupSchedSvc.Help.create.schedule.Create()

  $schedSpec = 'weekly'
# Create a specification based on the Help response

  $backupSchedSpec = $backupSchedSvc.Help.create.spec.Create()

  $backupSchedSpec.parts = @("common")

  $backupSchedSpec.location = "ftp://ftp01.corp.local"

  $backupSchedSpec.location_user = "backup"

  [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$backupSchedSpec.location_password = "VMware1!"

  $backupSchedSpec.enable = $true

  $recurSpec = $backupSchedSvc.Help.create.spec.recurrence_info.Create()

  $recurSpec.days = @("Sunday")

  $recurSpec.minute = '59'

  $recurSpec.hour = '23'

  $backupSchedSpec.recurrence_info = $recurSpec

  $retentSpec = $backupschedsvc.help.create.spec.retention_info.Create()

  $retentSpec.max_count = '5'

  $backupSchedSpec.retention_info = $retentSpec
# Create the backup job 

  $backupSchedSvc.create($schedSpec, $backupSchedSpec)
 

Это все соответствует запланированной задаче РК со следующими параметрами:

На портале VMware Labs на днях обновилась полезная утилита vCenter Workload Migration Utility до версии 3.0. Напомним, что это средство позволяет перенести виртуальные машины средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные).

Давайте посмотрим, что нового появилось в обновлении утилиты:

• Новый интерфейс плагина, который теперь полностью интегрирован с vSphere HTML5 Client и поддерживается как для vSphere, так и для окружений на базе VMware Cloud.
• Полный набор функций, такой же, как и у XVM UI.
• Поддержка миграций, инициированных на уровне хоста, кластера или пула ресурсов из дерева объектов vSphere Client.
• Классический интерфейс Standalone UI объявлен устаревшим, но все еще поддерживается.
• Возможность миграции сетей с одинаковыми именами.
• Сортировка и фильтрация списка ВМ, которые предполагается мигрировать.
• Улучшения, связанные с доработкой механизма отчетности.

Скачать Cross vCenter Workload Migration Utility 3.0 можно по этой ссылке.

На днях, еще до начала конференции VMworld Europe 2019, компания VMware рассказала об интересном сервисе - Skyline Health for vSAN. Как вы помните, сервис VMware Skyline - это проактивная технология VMware для предоставления расширенной технической поддержки некоторым клиентам для продуктов vSphere и NSX.

С помощью технологии VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут просматривать некоторые заключения о работе виртуальной инфраструктуры и основные рекомендации по ее улучшению, которые содержатся в специальном отчете Skyline Operational Summary Report (OSR).

Также инженеры техподдержки VMware в рамках решения проблем заказчиков могут видеть весь их Inventory, а также все их обращения в техническую поддержку (Support Requests, SRs). Все это позволяет службам Global Support Services (GSS) быстро и эффективно решать проблемы заказчиков, а что более важно - предотвращать их.

Новое решение от VMware объединяет 2 продукта - vSAN Health и сервис Skyline. Skyline Health for vSAN предоставляет пользователям инструменты для самостоятельного обследования процессов конфигурации, патчинга, апгрейда и безопасности решений vSAN 6.7. Самое приятное - это то, что все пользователи с активной поддержкой получают Skyline Health for vSAN бесплатно.

Решение Skyline Health использует данные о тысячах инсталляций VMware vSAN для проактивного обнаружения проблем в вашей инфраструктуре, при этом само оно не отправяляет наружу никаких чувствительных данных. Сервис Skyline интегрирован с базой знаний VMware KB, а также содержит в себе список лучших практик для устранения наиболее частно встречающихся проблем.

Для работы Skyline вам потребуется, чтобы vCenter имел доступ в интернет и был участником Customer Experience Improvement Program (CEIP). В плане интерфейса vSphere Client раздел "Skyline Health" заменит собой "Health" и будет содержать как рекомендации Skyline, так и суммарную информацию vSAN Health. Сервис Skyline Health будет доступен для vSphere 6.7P01 (или vSAN 6.7 U3a), а также более поздних версий платформы.

Кроме того, сам проект Skyline претерпел несколько изменений. Теперь появилось решение Skyline Advisor, которое предназначено для пользователей с уровнем поддержки Production / Premier. Это решение включает в себя поддержку таких продуктов, как vSphere, vSAN, NSX, vROps, Horizon. Помимо этого туда включается инфраструктура VMware Cloud Foundation и Dell EMC VxRail.

Также поддержка распространяется на такие компоненты, как решения VMware Cloud Foundation и Dell EMC VxRail, а также гиперконвергентные системы, созданные в кооперации с другими вендорами.

Решение Skyline Advisor расширяет поддержку продуктов VMware и для старых версий (например, vSphere 5.5). Также пользователи вместе с продуктом получают и решение LogAssist, которое автоматизирует сбор и загрузку логов (это может оказаться очень полезным при обращении в саппорт).

Пользователи поддержки уровня Premier получают еще несколько дополнительных функций, таких как расширенные рекомендации и отчеты, а также план по решению проблем и восстановлению правильной конфигурации инфраструктуры.

Решение VMware Skyline Health for vSAN будет доступно для пользователей в ближайшие месяцы.

На сайте проекта VMware Labs недавно появилась очередная интересная штука - средство Virtualized High Performance Computing Toolkit. С помощью этого пакета пользователи VMware vSphere, которым требуется поддержка виртуальных машин, работающих в сфере высоких нагрузок (High Performance Computing, HPC), могут упростить управление жизненным циклом таких специализированных конфигураций через vSphere API.

Как правило, задачи HPC требуют использования таких технологий, как vGPU и FPGA, а также RDMA interconnects для высокопроизводительных вычислений. Помимо возможностей управления конфигурациями, тулкит содержит средства, которые дают администраторам возможности по выполнению типовых задач в HPC-окружениях на виртуальной платформе - клонирование ВМ, определение Latency Sensivity, сайзинг машин по vCPU и памяти, а также некоторые другие.

Вот возможности Virtualized High Performance Computing Toolkit списком:

• Настройка устройств PCIe в режиме DirectPath I/O с использованием GPGPU, FPGA и RDMA interconnects.
• Настройка NVIDIA vGPU.
• Настройка RDMA SR-IOV (Single Root I/O Virtualization).
• Настройка  PVRDMA (Paravirtualized RDMA).
• Возможность простого создания и удаления виртуальных кластеров HPC с использованием файлов конфигурации.
• Выполнение частых задач vSphere - клонирование ВМ, настройка vCPU, памяти, резерваций, shares, Latency Sensitivity, коммутаторов Distributed Virtual Switch/Standard Virtual Switch, сетевых адаптеров и конфигураций.

С помощью тулкита вы сможете применить приведенные выше операции к одной или нескольким ВМ одновременно. Например, вот так выглядит клонирование машины на базе шаблона vhpc_clone с заданными кастомизациями памяти и CPU и добавление NVIDIA vGPU в соответствии с профилем vGPU по имени grid_p100-4q:

vhpc_toolkit> clone --template vhpc_clone --datacenter HPC_Datacenter --cluster COMPUTE_GPU_Cluster --datastore COMPUTE01_vsanDatastore --memory 8 --cpu 8 –-file VM-file

vhpc_toolkit> vgpu --add --profile grid_p100-4q --file VM-file

В файле VM-file должен содержаться список клонов ВМ, которые должны получиться в результате операции.

А вот такой командой можно собрать кластер под HPC-задачи в соответствии с конфигурацией, указанной в файле cluster.conf:

vhpc_toolkit> cluster --create --file cluster.conf

Больше подробностей об этом тулките можно получить в репозитории на GitHub вот тут. Скачать Virtualized High Performance Computing Toolkit можно там же.

В сентябре этого года мы писали о VMware Cloud Foundation 3.8.1 - комплексном программном решении, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

На днях компания VMware объявила о выходе обновленной архитектуры VMware Cloud Foundation 3.9.

Давайте посмотрим, что нового появилось в VCF 3.9:

• Поддержка апгрейдов на уровне кластера - теперь есть возможность выбрать отдельные кластеры в рамках домена рабочей нагрузки для обновления хостов ESXi.
• Возможность управления несколькими экземплярами Cloud Foundation из одной консоли.
• Домены рабочей нагрузки Virtual Infrastructure (VI) теперь поддерживают Fibre Channel (в дополнение к vSAN и NFS) как Principal Storage.
• Возможность пересборки конфигураций серверов Dell MX под нужды заказчиков.
• В SDDC Manager можно настроить бэкап NSX Managers на сервер SFTP таким образом, чтобы он находился в отдельной зоне отказа (fault zone). Рекомендуется зарегистрировать сервер SFTP на SDDC Manager после обновления и во время первоначальной настройки.
• Бета-возможность Developer Center - она позволяет получить доступ к Cloud Foundation API и примерам кода под SDDC Manager Dashboard.
• Поддержка Cloud Foundation API была существенно расширена, подробнее об этом рассказано тут.
• Bill of Materials (BoM) был обновлен до последних версий продуктов.

Вот список BoM для релиза VCF 3.9:

Project Pacific был одним из главных анонсов конференции VMworld в этом году, и VMware обращала на него особенное внимание. Это неудивительно - ведь VMware делает поддержку Kubernetes не для галочки. Тут дело в том, что многие пользователи планируют развертывание инфраструктуры контейнеризованных приложений на физической инфраструктуре - в этом случае не надо нести издержки на гипервизор и лицензии, а сами приложения в контейнерах работают быстро и имеют встроенные средства обеспечения доступности.

VMworld Europe 2019 – это не просто очередная конференция в сфере информационных технологий, это центр притяжения IT-специалистов со всего мира. Инновации, современные решения, возможность узнать много нового, почувствовать динамику быстро меняющейся IT-среды, встретить единомышленников и новых друзей – делают VMworld столь популярным. Команда «ИТ-ГРАД» будет вести прямую трансляцию самых последних новостей с ключевой конференции...

Недавно мы писали о новой версии платформы VMware Horizon 7.10 и новых версиях клиентов VMware Horizon Clients 5.2. Спустя несколько недель, компания VMware (в сотрудничестве с Microsoft) объявила о доступности публичной бета-версии пакета Horizon Audio-Optimization Pack for Microsoft Teams, который позволяет оптимизировать использование аудиоканала между участниками команд MT.

Напомним, что первым из таких оптимизаций стал пакет Horizon Virtualization Pack for Skype for Business, который предназначен для оптимизации голосовых и видеовызовов Skype в виртуальных ПК бизнес-пользователями приложения.

Теперь пришел и черед оптимизаций для Microsoft Teams. Пакет Horizon Audio-Optimization Pack позволяет полностью передать функции по обработке аудио-потока на сторону клиентского устройства, что позволяет организовать peer-to-peer каналы между участниками команды и эффективнее обрабатывать аудиоконференции.

Делается это средствами WebRTC. Сначала Microsoft Teams загружает тонкую прокладку из Javascript на виртуальную машину, которая соединяется с Horizon Agent через WebSocket. Команды WebRTC перенаправляются к Horizon Client, который работает в связке с Audio-Optimization Pack. Стек Teams Media Optimization (он же WebRTC плеер) обрабатывает команды через Horizon Agent, а также отправляет результаты обратно к Javascript на стороне гостевой ОС.

Плеер WebRTC отвечает за кодирование A/V-фреймов и посылает их к удаленному клиенту MT, а также принимает и декодирует их. Процесс можно проиллюстрировать следующей диаграммой:

Преимущества такого подхода очевидны - оптимизация потоков трафика за счет его локализации на уровне оконечных узлов и экономия процессорных ресурсов хост-серверов датацентра компании.

Загрузить бета-версию VMware Horizon Audio-Optimization Pack for Microsoft Teams можно по этой ссылке.

На днях компания VMware выпустила несколько небольших апдейтов своих продуктов. Во-первых, обновился управляющий сервер vSphere до версии VMware vCenter 6.7 Update 3a. В этом релизе новых возможностей не появилось, но было сделано несколько важных багофиксов. Они касаются подсистемы безопасности для процесса резервного копирования и восстановления vCenter (подробнее тут), а также компонентов Platform Services Controller и vSAN.

Скачать VMware vCenter 6.7 Update 3a можно по этой ссылке.

Во-вторых, обновился пакет для гоствых ОС - VMware Tools. Обновилась как одиннадцатая версия пакета VMware Tools 11.0.1 (напомним, что мы писали о VMware Tools 11), так и вышли VMware Tools 10.3.21 (эта ветка сделана для старых Linux-дистрибутивов).

Для тех, кто использует возможность "native service discovery" в vRealize Operations Manager 8.0, или использует продукт vRealize Operations Service Discovery Management Pack с прошлыми версиями vRealize Operations Manager (7.x или старше), обновление обязательно! Подробнее об этом написано в KB 75122.

Скачать VMware Tools 11.0.1 можно по этой ссылке, а 10.3.21 - по этой.

На днях компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 11.5. Напомним, что о прошлой версии, PowerCLI 11.4, мы писали в конце августа этого года.

Давайте посмотрим, что интересного появилось в PowerCLI 11.5:

1. Новые командлеты для управления библиотеками Content Library.

В последних версиях VMware vSphere функциональность библиотек Content Library была существенно доработана (кстати, это был один из первых сервисов, использовавших vSphere Automation REST API). PowerCLI старается не отставать, поэтому тут было добавлено 8 новых командлетов, а также была добавлена поддержка шаблонов (templates):

• New-ContentLibraryItem
• Set-ContentLibraryItem
• Remove-ContentLibraryItem
• Export-ContentLibraryItem
• New-ContentLibrary
• Set-ContentLibrary
• Get-ContentLibrary
• Remove-ContentLibrary

Вот пример опроса содержимого объекта библиотеки:

2. Обновление механизма vCenter Alarm Management.

В PowerCLI уже имеются средства для управления алармами vCenter, но их пользователям явно недостаточно. Новая версия PowerCLI имеет 6 новых и 3 обновленных командлета для управления определениями алармов, триггерами, а также для получения данных о типах событий и метриках.

Новые командлеты:

• New-AlarmDefinition
• Remove-AlarmDefinition
• New-AlarmTrigger
• Get-AlarmTrigger
• Get-EventType
• Get-Metric

Обновленные командлеты:

• New-AlarmAction
• New-AlarmActionTrigger
• Set-AlarmDefinition

Вот пример работы нового командлета, где создается определение аларма в vCenter:

3. Обновление модуля VMware Cloud on AWS.

Модуль для управления VMware Cloud on AWS (VMC) - это один из самых новых модулей. Ранее он использовался как средство низкоуровневого взаимодействия с инфраструктурой VMC. Теперь же этот низкоуровневый интерфейс был заменен на высокоуровневые команды для осуществления операций, необходимых пользователю.

Пример - теперь для создания объекта SDDC используется 1 команда вместо 20 строчек кода, которые требовались раньше:

А вот, собственно, новые командлеты, которые появились для VMC (подробнее - здесь):

• Get-VmcSddc
• Set-VmcSddc
• New-VmcSddc
• Remove-VmcSddc
• Add-VmcSddcHost
• Remove-VmcSddcHost
• Get-AwsAccount
• Get-AwsVpcSubnet

4. Обновленный модуль VMware Core.

Здесь, прежде всего, была доработана функциональность, связанная с тэгами. Командлет Get-Tag и параметр Tag для Get-VM были обновлены, также были обновлены и командлеты Get/Remove-TagAssignment.

Кроме того, базовые функции обогатились некоторыми полезными функциями. Например, теперь при создании виртуальной машины из шаблона средствами командлета New-VM появилась возможность настройки портгруппы через параметры NetworkName или Portgroup.

Также в vSphere 6.7 появилось новое свойство виртуальной машины CreateDate, которое теперь также поддерживается в командлетах, связанных с виртуальной машиной:

Больше информации о новых возможностях VMware PowerCLI 11.5 можно почерпнуть в следующих документах:

• VMware PowerCLI Change Log
• VMware PowerCLI 11.5.0 User’s Guide
• VMware PowerCLI 11.5.0 Cmdlet Reference

Update-Module -Name VMware.PowerCLI

Скачать VMware PowerCLI 11.5 можно по этой ссылке.

Мы не раз упоминали средство VMware AppDefense, которое позволяет защищать виртуальную инфраструктуру vSphere за счет наблюдения за нормальной сетевой активностью приложений и выявления подозрительных отклонений, вызываемых вредоносным ПО. Напомним, что решение AppDefense входит в состав VMware vSphere Platinum.

На днях компания VMware выпустила обновленный AppDefense 2.3, где появилась масса новых возможностей. Давайте на них посмотрим:

1. Действие Process Kill как ответ на возникшую угрозу.

Ранее в качестве ответной реакции на выявленное отклонение можно было использовать действия выключения ВМ, создание снапшота или приостановка машины (suspend). Теперь же есть возможность завершить любой из подозрительных процессов внутри гостевой ОС:

2. Поведенческие отметки времени (Behavior Timestamps).

В рамках концепции выдачи только необходимых привилегий пользователям или процессам для исполнения своих задач, AppDefense позволяет отслеживать какой сервис как себя вел и, главное, когда в последний раз это происходило (для этого есть поле last seen):

Все это очень помогает при ретроспективном анализе безопасности и аудите происходивших событий.

3. Улучшения классификации алертов и приведение в порядок узких мест на базе серьезности инцидентов.

Теперь алерты очень детально разделяются по степени критичности, а отсюда уже следует следующее улучшение - теперь для критичных событий можно сделать радикальные действия (выключить ВМ), а для небольших отклонений - просто оповестить администратора или отключить сервис.

4. Новые роли для AppDefense SaaS portal.

Теперь можно разделять роли еще более гранулярно и выделять пользователям портала только самые необходимые привилегии. Например, такое можно сделать для сотрудников сектора ИБ, а также команд SecOps.

5. Установка и апгрейд без перезагрузок.

Модуль AppDefense для гостевой ОС поставляется вместе с VMware Tools, что позволяет организовать очень мягкое взаимодействие с гостевой системой, не подразумевающее частых перезагрузок, даже в случае апгрейда решения. Для такого образа действий вам потребуется VMware Tools 11 или более поздняя версия пакета (где как раз встроена функция обновления AddDefense без перезагрузок).

6. Поддержка DNS для разрешенного поведения (Allowed Behaviors).

Теперь не нужно искать, для какой системы какой IP-адрес нужно использовать. Для настройки разрешенного поведения можно использовать человеческие имена сервисов из DNS.

7. Поддержка VMware NSX-T.

Теперь AppDefense может работать в комплексе с решением по агрегации и защите сетей виртуального датацентра NSX-T (в дополнение к NSX-V) для переведения виртуальных машин на карантин. Это позволяет настраивать более гранулярные ответные действия, которые AppDefense предпринимает как реакции на вредоносные действия.

8. Сканирование на уязвимости и приоритизация рисков.

Вот пример представления "AppDefense 2.3 – VM OS Vulnerabilities View", которое позволяет оценить имеющиеся слабые места ОС:

Вот уже представление "AppDefense 2.3 – VM Guest Monitoring View":

AppDefense 2.3 позволяет приоритизировать возможные риски и представить узкие места на дэшбордах, которых весьма немало в продукте.

Скачать VMware AppDefense 2.3 можно по этой ссылке. Полный список новых возможностей и изменений приведен тут.

На сайте проекта VMware Labs появилась первая версия мультиплатформенного клиента для кластеров Kubernetes - KubeWise. Так же, как и kubectl, KubeWise требует только валидный файл kubeconfig (или несколько) для взаимодействия с одним или несколькими кластерами.

Данное средство представляет собой настольное приложение на базе HTML, JavaScript, CSS и Node.js, работающее на базе фреймворка Electron. Для запуска вам потребуется:

• Mac OS, Windows или Linux (на базе Debian).
• kubectl v1.14.0+, развернутый для управления кластерами Kubernetes v1.14.0+.

Основные возможности KubeWise:

• Поддержка нескольких файлов kubeconfig для разных кластеров.
• Взаимодействие в интерфейсе с самыми часто используемыми сущностями Kubernetes - узлами, пространствами имен и т.п.
• Терминал с возможностью установки переменной окружения KUBECONFIG.
• Генерация кастомных файлов kubeconfig для заданного пространства имен.
• Расширенные возможности безопасности (RBAC, пароли, сервисные аккаунты).

Надо понимать, что данная утилита - это произведение сотрудников VMware, которые никак не связаны с Linux Foundation и Cloud Native Computing Foundation (CNCF).

Скачать KubeWise можно по этой ссылке.

Вчера наш один из наших читателей в статье про новые версии VMware Dynamic Environment Manager 9.9 и App Volumes 2.18 обратил наше внимание на то, что уже доступна бета-версия решения VMware App Volumes 4.0 (на него доступен апгрейд с версии 2.18).

Напомним, что решение App Volumes предназначено для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам.

Ключевыми особенностями решения App Volumes являются следующие функции:

• Decoupling package management and delivery - позволяет владельцами приложений свободно работать с пакетами, отдельно организовывать их доставку и быстро обслуживать пользовательские запросы.
• Manage the full lifecycle of an application - возможность накатывания обновления приложения просто путем репаблишинга пакета в рамках настраиваемого рабочего процесса.
• Packaging once and deploying everywhere - средства для онпремизного и облачного массового развертывания приложений, которые требуют подготовки только один раз, после чего свободно раскатываются на любое число хостов.

Новые возможности App Volumes 4.0 представлены в трех категориях:

• Single App Packaging - теперь в пределах единого воркфлоу можно совмещать процесс упаковки и доставки приложений в любой комбинации и в рамках конфигурации с несколькими VMDK-дисками.
• Application Lifecycle Management - средства по обслуживанию жизненного цикла развертываемых приложений. Это позволяет убедиться в том, что выбранные пользователи получают правильные версии приложений в нужное время.
• Smart Delivery и On-Demand Applications - эти возможности позволяют снять ограничения на количество приложений, которые будут доставляться пользователям. Приложения, которые развертываются по запросу - важная особенность для больших инсталляций.

Жизненный цикл распространяемого через App Volumes 4.0 приложения теперь выглядит следующим образом:

• Администратор создает приложение нужной версии и сохраняет метаданные, которые отражают параметры окружения, в котором пакет создавался.
• С помощью App Volumes и ThinApp администратор убеждается, что данная версия приложения работает в разных ОС и не конфликтует с другими приложениями.
• В пилотной среде происходит тестирование данной версии приложения на некотором наборе релевантных пользователей.
• Если тестирование прошло успешно, происходит публикация приложений в производственной среде. Назначение прав происходит тем же образом, что и в старом App Volumes версий 2.x.
• После выхода новых обновлений происходит списание старой версии приложений App Volumes.

Скачать бета-версию VMware App Volumes 4.0 можно по этой ссылке. Документация доступна вот тут:

• App Volumes Beta Installation Guide
• App Volumes Beta Administration Guide

Многие из вас, прочитав заголовок этой новости, не вспомнят продукта Dynamic Environment Manager у VMware. Но тут все просто - так теперь называется решение по управлению пользовательскими окружениями на уровне ОС VMware User Environment Manager (напомним, что о прошлой версии UEM 9.8 мы писали вот тут).

Ранее мы рассказывали о новых возможностях VMware Horizon 7.10 и VMware Horizon Clients 5.2, а сегодня посмотрим, что нового появилось в VMware Dynamic Environment Manager 9.9 и App Volumes 2.18 (прошлую версию App Volumes мы упоминали вот тут).

В Dynamic Environment Manager 9.9 появилось всего пара нововведений: во-первых, это функция Active Directory Attribute Condition. Она позволяет проверить соответствует ли заданный аттрибут Active Directory заданному критерию.

Ну и, во-вторых, это расширенная конфигурация для сбора логов и диагностики продукта:

Скачать VMware DEM 9.9 можно по этой ссылке. Кстати, очень крутое руководство по продукту находится тут.

Что касается VMware App Volumes 2.18, то тут появились следующие новые возможности:

• Централизованное управление задачами - администраторы могут использовать вкладку Jobs в разделе Activity графического интерфейса App Volumes Manager для тонкой настройки задач в больших инсталляциях. Более подробно об этом рассказано здесь.
• Появилась поддержка ОС Windows Server 2019.
• Была добавлена поддержка протокола IPv6.
• Обновилась подсистема безопасности.
• Добавлена поддержка накатывания апгрейда серверов App Volumes Manager 2.18 на более поздние версии.

Скачать VMware App Volumes 2.18 можно по этой ссылке. Release Notes находятся здесь.

На сайте проекта VMware Labs очередное обновление - вышла новая версия продукта Virtual Machine Compute Optimizer 2.0. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.

Напомним, что о первой версии данной утилиты мы писали летом этого года вот тут. Давайте посмотрим, что нового появилось в Virtual Machine Compute Optimizer 2.0:

• Собираются приоритеты найденных несоответствий.
• Вывод деталей найденных несоответствий.
• Собирается информация о кластере, чтобы определить совместимость оборудования хостов на уровне кластера.
• В отчет добавляется информация, если виртуальная машина использует разные физические pNUMA узлы, которые транслируются в гостевую ОС.
• Добавляется информация об измененных расширенных настройках на уровне ВМ или хоста ESXi, касающихся представления pNUMA-узлов в гостевую ОС.
• В отчет попадают ВМ, если у них число vCPU (с использованием гипертрэдов как vCPU) превышает число физических ядер CPU на хосте ESXi.
• Возможность использовать отдельную функцию Get-OptimalvCPU для получения еще большей гибкости.

Скачать VM Compute Optimizer 2.0 можно по этой ссылке. Данный сценарий PowerCLI можно запустить различными способами, смотрите сопровождающий PDF (можно выбрать в комбобоксе при загрузке) для получения более детальной информации.

Интересно наблюдать за тем, какими темпами компания VMware наверстывает упущенное по наращиванию функциональности мобильного клиента для VMware vSphere. Еще совсем недавно мы писали о версии 1.5, а на днях был выпущен уже обновленный VMware vSphere Mobile Client 1.6.

Давайте посмотрим, что там появилось нового:

• Хосты ESXi теперь можно перезагружать из интерфейса мобильного клиента.
• Последние задачи теперь можно видеть в представлении Tasks (статусы running/in-progress).
• Был проведен редизайн карточек объектов (ВМ, хост, кластер и задача).
• Быстрые действия с объектом теперь можно вывести по тапу на него.
• Карточка виртуальной машины содержит скриншот гостевой ОС, который можно увеличить, тапнув на него.
• На дэшборд был добавлен портлет обратной связи, который позволяет написать разработчикам отзыв о приложении.
• Для хостов ESXi теперь доступы графики производительности.
• Меню навигации было укрупнено, поэтому теперь проще попадать по его элементам.

Скачать обновленный vSphere Mobile Client 1.6 можно по этим ссылкам:

• Android (доступно как Early access приложение).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.

В конце сентября мы писали о новых возможностях решения для виртуализации и доставки ПК и приложений предприятия VMware Horizon 7.10, но забыли рассказать о новых функциях клиентов Horizon Clients. Время восполнить этот пробел и посмотреть, что нового появилось в Horizon Clients версии 5.2 для разных платформ.

Новое в VMware Horizon Client 5.2 for Windows:

• Функция "Log in as current user" поддерживается для однонаправленных трастовых доменов.
• Функци Real-Time Audio-Video и scanner redirection поддерживаются в режиме вложенной виртуализации (см. подробности в KB 67248).
• Улучшенная производительность отображения картинки и уменьшение использования CPU клиентской системы за счет использования Lightweight Protocol Client вместо устаревшей консоли vmware-remotemks.
• Улучшенная производительность 3Dconnexion SpaceMouse с возможностью перенаправления USB и протоколом VMware Blast.
• Можно использовать Horizon Client для изменения разрешения и масштабирования удаленного десктопа (подробнее тут).
• Можно использовать групповые политики для настройки комбинаций горячих клавиш, например, для комбинации клавиш получения и отпускания фокуса ввода в гостевую ОС (подробнее тут).
• Возможность синхронизации нажатых состояний клавиш Num Lock, Scroll Lock и Caps Lock с клиентской системы средствами групповых политик (подробнее тут).
• Возможность разрешить проверку сертификатов для вторичных соединений через SSL прокси-сервер. Эта возможность применяется к Blast Secure Gateway и соединениям через защищенный туннель. Подробнее об этом тут.
• Возможность разрешать и запрещать соединения VMware Blast через SSL прокси-сервер. Подробнее тут.
• Возможность выбрать букву диска при перенаправлении клиентских устройств в ВМ. Как это сделать, описано тут.
• Поддержка функции Browser Redirection, которая появилась в Horizon Agent 7.10. Содержимое веб-сайтов в Google Chrome рендерится на клиентской системе вместо виртуальной машины, что снимает нагрузку с хост-серверов датацентра. Подробнее тут.
• Возможность перенаправления нескольких веб-камер и микрофонов с функциями Real-Time Audio-Video. Эта возможность требует Horizon Agent 7.10. Она не работает с опубликованными десктопами и приложениями, о ее настройке можно почитать тут.

Новое в VMware Horizon Client 5.2 for Linux:

• Обновленная поддержка 64-битных дистрибутивов RHEL:
  
  • RHEL 8 поддерживается с некоторыми ограничениями (только X11 display server protocol и без поддержки Skype for Business Virtualization).
  • RHEL 7.7 теперь поддерживается полностью.
  • RHEL 6.x больше не поддерживается, ввиду отсутствия там поддержки GTK 3.
• Поддержка GTK 3 toolkit и library для улучшенной поддержки отображения графики и прочих возможностей.
• Теперь можно использовать запуск Horizon Client в минимизированном режиме (ключ --launchMinimized), когда окно клиента спрятано в бэкграунде.
• Поддержка High Efficiency Video Decoding (HEVC) при добавлении параметра view.allowEnableHEVC, а также возможность использования прокси-сервера для VMware Blast.
• Прекращена поддержка параметров view.defaultAppSize и --appSize=.
• Прекращена поддержка параметров view.disableMaximizedApp и --disableMaximizedApp.

Новое в VMware Horizon Client 5.2 for Mac OS:

• Более быстрое восстановление соединения при открытии крышки ноутбука.
• Улучшенная производительность отображения картинки и уменьшение использования CPU клиентской системы за счет использования Lightweight Protocol Client вместо устаревшей консоли vmware-remotemks.
• Улучшенная производительность 3Dconnexion SpaceMouse с возможностью USB redirection и протоколом VMware Blast.
• Можно использовать Horizon Client для изменения разрешения и масштабирования удаленного десктопа (подробнее тут).
• Поддержка High Efficiency Video Decoding (HEVC), а также возможность использования прокси-сервера для VMware Blast. Подробнее об этом тут.
• Возможность разрешить проверку сертификатов для вторичных соединений через SSL прокси-сервер. Эта возможность применяется к Blast Secure Gateway и соединениям через защищенный туннель. Подробнее об этом тут.

Новое в VMware Horizon Client 5.2 for iOS:

• Когда вы используете Workspace ONE UEM для доставки клиентов Horizon Client на iOS-устройства, вы можете настроить позицию камеры и качество видео. Подробнее об этом рассказано тут.

Новое в VMware Horizon Client 5.2 for Android:

• Поддержка Android 10 (Q) для установки клиента.
• Поддержка режима Dark mode на Android 10 (Q) и более поздних устройствах.
• Использование консоли Google Admin для настройки приложения Horizon Client на устройствах Chromebook (таких как масштабирование и разрешение экрана, режим нескольких мониторов и другое). Подробнее об этом тут.
• Использование Workspace ONE UEM для настройки приложения Horizon Client. Подробнее об этом тут.

Как обычно, все клиенты VMware Horizon Clients 5.2 можно скачать по этой ссылке (там вы увидите, что клиенты версии 5.0, но при нажатии на загрузку, вы увидите страничку, где указана версия 5.2).

Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах Intel (например, Meltdown и Spectre), которые потенциально могли приводить к получению контроля над исполнением систем (в том числе виртуальных машин), работающих на базе определенных CPU. Об этом можно прочитать у нас, например, тут и тут.

При обнаружении таких уязвимостей Intel выпускает обновления микрокода (firmware) для своих процессоров, которые нужно применить как к серверам ESXi, так и к виртуальным машинам. Например, для устранения уязвимости типа MDS была добавлена инструкция MD_CLEAR, которую гостевая ОС может обнаружить и использовать для защиты от определенных уязвимостей.

В виртуальной среде виртуальная машина - это VMX-процесс на сервере ESXi, который обеспечивает исполнение гостевой операционной системы. При этом ВМ может перемещаться между серверами ESXi средствами vMotion, поэтому она может иметь довольно большой аптайм (больше самих хостов, где она работает) и, как следствие, долго не обновлять виртуальное аппаратное обеспечение.

В то же время, для патчинга некоторых уязвимостей нужно обновить микрокод CPU и пересоздать VMX-процесс виртуальной машины, чтобы она могла инициализировать и подхватить обновления микрокода (что происходит только при первой загрузке). Простая перезагрузка тут не поможет, так как в этом случае пересоздания VMX не происходит, а лишь идет ребут гостевой системы. Кстати, это вам на заметку - если хотите "почистить" виртуальную машину, то лучше выключить и включить ее, а не перезагружать.

Чтобы выполнить процедуру выключения и включения, начиная с vSphere 6.5 Update 3 и vSphere 6.7 Update 3, компания VMware ввела инструкцию vmx.reboot.PowerCycle, которая выполняет цикл питания виртуальной машины. Этот параметр, который можно добавить в VMX-файл, считывается со стороны VMware Tools, которые уже совместно с хостом ESXi обеспечивают исполнение этого цикла.

Чтобы добавить этот параметр в VMX-файл через PowerCLI, вы можете использовать следующую команду:

New-AdvancedSetting -Entity YOUR_VM_NAME -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Это же можно сделать и для групп виртуальных машин, например, находящихся в папке Test Group 1:

Get-Folder "Test Group 1" | Get-VM | New-AdvancedSetting -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.

После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.

Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):

Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.

В случае, если у вас где-то поменялось железо на хостах, то нужно выполнить перезапуск цикла питания виртуальных машин, что приведет кластер EVC к единому базовому уровню и позволит избавиться от потенциальных проблем.

На сайте проекта VMware Labs за последние дни появилась пара интересных обновлений полезных утилит. Первое - это апдейт средства vSAN Performance Monitor 1.2, предназначенного для мониторинга и визуализации (в Grafana) метрик в среде отказоустойчивых кластеров VMware vSAN.

С помощью этих данных администраторы смогут диагностировать проблемы, а также распознавать текущие и намечающиеся узкие места в инфраструктуре, которые могут оказаться причиной низкой производительности.

В версии vSAN Performance Monitor 1.2 появились следующие улучшения:

• Исправлена проблема с настройкой CA-сертификатов
• Некоторые доработки агента, собирающиего данные
• Убран анонимный сбор статистики от influxdb

Скачать vSAN Performance Monitor 1.2 можно по этой ссылке.

Второе существенное обновление в Labs - это апдейт утилиты vRealize Operations REST Notifications Helper 1.3. О прошлой версии 1.2 этого средства мы писали вот тут. Напомним, что эта штука позволяет администратору vROPs изменять свойства алерта перед его отправкой на сторону.

В данном обновлении появились следующие новые функции:

• Добавлена конфигурация предпочитаемого HTTP-запроса
• Добавлена конфигурация маппинга критичности алерта
• Добавлены черные списки с полем resourceName
• Добавлена настройка структуры конечного устройства (endpoint) для обработки разного поведения на базе состояний сработавшего/несработавшего триггера
• Добавлено описание симптомов в одну строку как и для рекомендаций.
• Различные исправления ошибок

Обновленный vRealize Operations REST Notifications Helper 1.3 можно скачать по этой ссылке.

На сайте VMware обновился основной документ Product Lifecycle Matrix, в котором приведены дата доступности продукта для загрузки, окончание поддержки, завершение технического сопровожнения и дата снятия с продаж.

Документ обновился совсем недавно и актуален на 1 октября 2019 года (кстати, обращайте внимание на колонку Notes и расшифровку этих заметок в конце документа):

Для каждого из продуктов приведен тип политики поддержки по отношению к обслуживанию жизненного цикла серии продуктов. VMware разделяет эти политики на следующие типы:

• APP: - Application Platform Policy
• EAP: - Enterprise Application Policy
• EDP: - Enterprise Desktop and Mobility Policy
• EIP: - Enterprise Infrastructure Policy
• GSP: - General Support Policy
• N-2: - N-2 Policy
• N/A: - No lifecycle policy applies
• PDP: - Personal Desktop Policy
• VI3P: - VMware Infrastructure 3 Policy

Скачать VMware Product Lifecycle Matrix можно по этой ссылке. Если у вас большая инфраструктура, где есть продукты довольно древних версий, то будет полезным занести в закладки этот документ, чтобы понимать, когда нужно запланировать обновление, чтобы не остаться без поддержки от вендора.

Довольно интересная штука обнаружилась среди бесплатных средств для мониторинга виртуальной инфраструктуры VMware vSphere - утилита с неблагозвучным названием LPAR2RRD. Оказывается на днях вышла ее версия 6.1, где появилось несколько новых возможностей.

Сама утилита LPAR2RRD - это бесплатное средство мониторинга для сред VMware vSphere и IBM Power Systems без агентов, которое позволяет отслеживать различные аспекты производительности хостов и виртуальных машин. Если же поставить агенты в ОС, то решение будет работать и с такими системами, как AIX & Linux, IBM i (AS/400) и Solaris.

Полнофункциональное демо этого продукта доступно по этой ссылке.

Надо отметить, что продукт вполне развивается и обновляется разработчиками, несмотря на свою бесплатность. В данном решении есть следующие основные возможности для мониторинга сред VMware vSphere:

• Мониторинг ресурсов
  • vCenter
  • Cluster
  • Resource Pool
  • Datastore
  • ESXi
  • Virtual Machine
• Метрики мониторинга
  • Производительность CPU (GHz, число CPU, показатель CPU ready)
  • Использование памяти (reserved, granted, consumed, active, baloon, swap in, limit)
  • Производительность LAN в МБ/сек
  • Производительность дисковой подсистемы (МБ/сек, IO per sec, latency в миллисекундах)
  • Использование дисков (ГБ)
• Другие возможности
  • Функция Trends
  • Исторические отчеты
  • Функции Heatmap
  • Возможность масштабирования графиков

Для тех, кто знаком с этим решением, вот список новых возможностей LPAR2RRD 6.1, вышедшей в октябре:

• Новый раздел Dashboard - полностью кастомизабельное пространство для графиков и диаграмм. Пользователь может менять размер графиков, создавать группы и двигать графики между ними.
• Раздел Heatmap - добавлена визуализация в сортируемых и фильтруемых таблицах.
• Улучшенная конфигурация через REST API для IBM Power Systems в части виртуальных сетей vSCSI и NPIV.
• Поддержка папок для vSphere (VM, Datastores).
• Таблица использования пространства виртуальными машинами в кластере (VM SPACE).
• Поддержка формата CSV в компоненте Reporter.
• Структура меню Hyper-V консолидирована по использованию ресурсов на вкладках вместо подразделов меню.
• Поддержка Solaris: мониторинг пулов.
• Reporter: поддержка Solaris и Hyper-V.
• Reporter: поддержка функционала TOP10 (графики можно вывести в pdf).
• Reporter: доступен файл с рекомендациями конфигурации в формате CSV.
• Поддержка кастомных групп для Hyper-V.
• Улучшения контроля доступа (ACL) - роль read-only.
• Множество небольших улучшений и багофиксов для следующих платформ:
  • IBM Power Systems: HMC REST API
  • Oracle Solaris
  • Microsoft Windows и Hyper-V

Скачать LPAR2RRD можно абсолютно бесплатно в виде виртуального модуля (Virtual Appliance) вот здесь.

Некоторое время назад мы писали о новых возможностях продукта VMware vCloud Director 10.0, которые раскрыл Daniel Paluszek. На днях он сделал еще очень полезную диаграмму, которая раскрывают логику миграции на vCD 10 с предыдущих версий.

Daniel использовал утилиту MindNode для составления данной диаграммы апгрейда на vCD 10. Как видно на картинках, там описаны разные варианты исходной системы, например, вы решите пойти по пути обновления только Linux / External PostgreSQL (PgSQL) с раздельной инсталляцией vCD или сделаете интегрированные виртуальные модули vCloud Director.

Диаграмма доступна как с фоном, так и с прозрачностью PNG-формата:

Для Linux-систем Daniel отмечает следующие моменты:

1. vCD 10.0 поддерживает только PostgreSQL, у него нет больше поддержки Microsoft SQL Server. Oracle уже прекратил поддерживаться ранее, поэтому все пути миграции ведут на PgSQL в данных диаграммах.
2. Использование виртуального модуля vCD позволяет обеспечить высокую доступность PgSQL, но в случае сбоя нужно будет вручную переключаться на реплику.
3. Использование внешнего экземпляра PostgreSQL полностью поддерживается. Но нужно внимательно следить за конфигурацией соединения к БД.
4. VMware будет продолжать поставлять как установщик, так и виртуальный модуль vCD. Поэтому можно использовать оба варианта, в зависимости от нужд вашей команды.

Более подробно о данных диаграммах можно почитать у Daniel Paluszek.

Часто при миграциях vMotion виртуальной машины с одного хоста ESXi на другой возникает проблема, источник которой не очень понятен. Большинство администраторов знают основные требования vMotion, также при миграции иногда показываются информационные сообщения, отражающие причину, по которой процесс завершился неудачно.

Но такое бывает не всегда, поэтому давайте посмотрим, как правильно искать причины ошибок vMotion в логах хостов. Для начала напомним основные причины проблем с vMotion:

• Проблемы сетевых соединений vMotion
  • Хосты ESXi не пингуются или отваливаются по таймауту в 20 секунд.
  • Несоответствие MTU между интерфейсом VMkernel и данным параметром в сети (на коммутаторах или маршрутизаторах).
  • Неправильная конфигурация сети на хостах ESXi.
• Проблемы хранилищ
  • Целевой датастор недоступен или переведен в статус APD (All Paths Down).
  • Таймаут операций ввода-вывода (I/O) составляет 20 секунд или более.
• Операция vMotion прошла успешно, но наблюдаются проблемы с гостевой ОС.
  • Ошибка VM network is not reachable – на уровне layer-2 нет соединения на целевом хосте ESXi.
• Ошибки, связанные с ресурсами.
  • В течение долгого времени хост не может выделить память виртуальной машине.
  • Свопирование идет очень долго, что приводит к вываливанию vMotion по таймауту.

При траблшутинге vMotion, в первую очередь, проверьте, что в вашей инфраструктуре соблюдаются основные требования, приведенные здесь.

С точки зрения логирования процесса vMotion, он устроен следующим образом:

Из картинки видно, что 4 лог-файла можно найти на хосте ESXi и один - на сервере vCenter.

Демоны vCenter Daemon (VPXD), vCenter Agent (VPXA) и Host Daemon (hostd) - это основные службы, которые отвечают за процесс миграции vMotion, и именно там следует начинать искать проблему. Что касается компонентов, отвечающих за реализацию на стороне ВМ - это процесс VMX и службы VMkernel.

Первый шаг траблшутинга - это найти Operation ID (opID) операции vMotion в логах. Этот opID отсылает уже к нужному Migration ID на обоих хостах ESXi.

VPXD-лог на vCenter Server позволит найти opID. Для этого залогиньтесь на VCSA (vCenter Server Appliance) и выполните команду:

grep "relocate" /var/log/vmware/vpxd/vpxd-*.log | grep BEGIN

В выводе команды вы найдете нужный opID:

/var/log/vmware/vpxd/vpxd-214.log:2019-09-24T15:38:10.042Z info vpxd[29243] [Originator@6876 sub=vpxLro opID=jzlgfw8g-11824-auto-94h-h5:70003561-20] [VpxLRO] — BEGIN task-8031 — vm-269 — vim.VirtualMachine.relocate — 52b17681-35d1-998b-da39-de07b7925dda(520681db-25b7-c5d6-44d7-6a056620e043)

Далее, зная opID, вы можете найти Migration ID в hostd-логах на соответствующих хостах ESXi. Делается это следующей командой:

grep jzlgfw8g-11824-auto-94h-h5:70003561-20 /var/log/hostd.log | grep -i migrate

Исходный хост ESXi

2019-09-24T15:38:47.070Z info hostd[2100388] [Originator@6876 sub=Vcsvc.VMotionSrc.3117907752192811422 opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-10-e036 user=vpxuser:VSPHERE.LOCAL\Administrator] VMotionEntry: migrateType = 1 2019-09-24T15:38:47.072Z info hostd[2100388] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/b86202d8-fb958817-0000-000000000000/NH-DC-02/NH-DC-02.vmx opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-10-e036 user=vpxuser:VSPHERE.LOCAL\Administrator] VigorMigrateNotifyCb:: hostlog state changed from success to none

Целевой хост ESXi

2019-09-24T15:38:47.136Z info hostd[2099828] [Originator@6876 sub=Vcsvc.VMotionDst.3117907752192811422 opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-2c-3c35 user=vpxuser:VSPHERE.LOCAL\Administrator] VMotionEntry: migrateType = 1

На стороне VMkernel вы можете найти информацию о неудачной миграции следующей командой:

grep VMotion /var/log/vmkernel*

Исходный хост ESXi:

019-09-24T15:38:47.402Z cpu13:46101760)VMotionUtil: 5199: 3117907752192811422 S: Stream connection 1 added.

2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 2062: Allocating pool 0.

2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.

2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

2019-09-24T15:38:47.445Z cpu8:46092538)VMotion: 8134: 3117907752192811422 S: Requiring explicit resume handshake.

2019-09-24T15:38:47.445Z cpu13:46101760)XVMotion: 3384: 3117907752192811422 S: Starting XVMotion stream.

2019-09-24T15:39:34.622Z cpu14:46101762)VMotion: 5426: 3117907752192811422 S: Disk copy complete, no bandwidth estimate.

2019-09-24T15:39:34.905Z cpu24:46092539)VMotion: 5281: 3117907752192811422 S: Stopping pre-copy: only 37 pages left to send, which can be sent within the switchover time goal of 0.500 seconds (network bandwidth ~185.134 MB/s, 1536000% t2d)

2019-09-24T15:39:34.965Z cpu13:46101760)VMotionSend: 5095: 3117907752192811422 S: Sent all modified pages to destination (network bandwidth ~281.100 MB/s)

2019-09-24T15:39:35.140Z cpu15:46101757)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.

2019-09-24T15:39:35.140Z cpu15:46101757)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

Целевой хост ESXi:

2019-09-24T15:38:47.397Z cpu15:2099283)VMotionUtil: 5199: 3117907752192811422 D: Stream connection 1 added.

2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 2062: Allocating pool 0.

2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.

2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

2019-09-24T15:38:47.440Z cpu3:3543984)VMotion: 8134: 3117907752192811422 D: Requiring explicit resume handshake.

2019-09-24T15:39:34.907Z cpu3:3543984)VMotionRecv: 761: 3117907752192811422 D: Estimated network bandwidth 205.138 MB/s during pre-copy

2019-09-24T15:39:34.960Z cpu3:3543984)VMotionRecv: 2961: 3117907752192811422 D: DONE paging in

2019-09-24T15:39:34.960Z cpu3:3543984)VMotionRecv: 2969: 3117907752192811422 D: Estimated network bandwidth 200.096 MB/s during page-in

2019-09-24T15:39:35.059Z cpu6:3543972)VMotion: 6675: 3117907752192811422 D: Received all changed pages.

2019-09-24T15:39:35.067Z cpu1:3543972)VMotion: 6454: 3117907752192811422 D: Resume handshake successful

2019-09-24T15:39:35.082Z cpu6:3543980)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.

2019-09-24T15:39:35.082Z cpu6:3543980)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

В выводе вы можете увидеть такие интересные вещи, как, например, средняя скорость (average bandwidth), которая была получена при передаче данных (см. вывод).

В папке с виртуальной машиной находится файл vmware.log, в котором также можно найти информацию о неудавшемся vMotion с учетом исходного и целевого IP-адресов хостов ESXi:

2019-09-24T15:38:47.280Z| vmx| I125: Received migrate ‘from’ request for mid id 3117907752192811422, src ip <192.168.200.93>.
2019-09-24T15:38:47.280Z| vmx| I125: MigrateSetInfo: state=8 srcIp=<192.168.200.93> dstIp=<192.168.200.91> mid=3117907752192811422 uuid=4c4c4544-004a-4c10-8044-c7c04f4d4e32 priority=high
2019-09-24T15:38:47.282Z| vmx| I125: MigID: 3117907752192811422
2019-09-24T15:39:34.971Z| vmx| I125: Migrate_Open: Restoring from <192.168.200.93> with migration id 3117907752192811422
2019-09-24T15:39:35.023Z| vmx| I125: Migrate_Open: Restoring from <192.168.200.93> with migration id 3117907752192811422

Некоторое время назад мы писали о новых возможностях решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware vSAN 6.7 Update 3. Среди прочего там появилось пара расширенных настроек, на которые обратил внимание Cormac Hogan. Давайте посмотрим, чем управляют эти Advanced Options в кластере.

Чтобы увидеть новые опции, надо в vSphere Client пойти в Cluster > Configure > vSAN > Services > Advanced Options, где можно увидеть параметры Large Cluster Support и Automatic Rebalance:

Первая настройка, как понятно из названия, регулирует возможность создания кластеров, которые имеют более 32 узлов. Ранее, чтобы расширить кластер, нужно было выставить параметр TcpipHeapMax на всех его хост-серверах ESXi. Теперь это удобно сделано в Advanced Options и применяется на уровне всего кластера.

Настройка Large Cluster Support требует перезагрузки каждого из хост-серверов:

Если вы не перезагрузите хосты, что в разделе статуса "vSAN extended configuration in sync" будут отображаться ошибки:

Вторая настройка, Automatic Rebalance, относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства. По умолчанию пороговое значение составляет 30%, что означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.

Также в разделе vSAN Disk Balance вы найдете информацию по использованию дисковой подсистемы кластера:

В случае, если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.

На блогах VMware появилась интересная статья о том, как работает связка кэширующего яруса (Cache tier) с ярусом хранения данных (Capacity tier) на хостах кластера VMware vSAN в контексте производительности. Многие пользователи задаются вопросом - а стоит ли ставить более быстрые устройства на хосты ESXi в Capacity tier и стоит ли увеличивать их объем? Насколько это важно для производительности?

Системы кэширования работают в датацентре на всех уровнях - это сетевые коммутаторы, процессоры серверов и видеокарт, контроллеры хранилищ и т.п. Основная цель кэширования - предоставить высокопроизводительный ярус для приема операций ввода-вывода с высокой интенсивностью и малым временем отклика (это обеспечивают дорогие устройства), после чего сбросить эти операции на постоянное устройство хранения или отправить в нужный канал (для этого используются уже более дешевые устройства).

В кластере vSAN это выглядит вот так:

Второе преимущество двухъярусной архитектуры заключается в возможности манипуляции данными не на лету (чтобы не затормаживать поток чтения-записи), а уже при их сбрасывании на Capacity tier. Например, так работают сервисы компрессии и дедупликации в VMware vSAN - эти процессы происходят уже на уровне яруса хранения, что позволяет виртуальной машине не испытывать просадок производительности на уровне яруса кэширования.

Общая производительность двухъярусной системы зависит как от производительности яруса хранения, так и параметров яруса кэширования (а именно скорость работы и его объем). Ярус кэширования позволяет в течение определенного времени принимать операции ввода-вывода с очень большой интенсивностью, превышающей возможности приема яруса хранения, но по прошествии этого времени буфер очищается, так как требуется время для сброса данных на уровень постоянного хранения.

С точки зрения производительности это можно представить так (слева система с ярусом кэширования и хранения, справа - только с ярусом хранения):

Оказывается, в реальном мире большинство профилей нагрузки выглядят именно как на картинке слева, то есть система принимает большую нагрузку пачками (burst), после чего наступает некоторый перерыв, который устройства кэширования кластера vSAN используют для сброса данных на постоянные диски (drain).

Если вы поставите более производительное устройство кэширования и большего объема, то оно сможет в течение большего времени и быстрее "впитывать" в себя пачки операций ввода-вывода, которые возникают в результате всплесков нагрузки:

Но более быстрое устройство при равном объеме будет "наполняться" быстрее при большом потоке ввода-вывода, что уменьшит время, в течение которого оно сможет обслуживать такие всплески на пиковой скорости (зато во время них не будет проблем производительности). Здесь нужно подбирать устройства кэширования именно под ваш профиль нагрузки.

С точки зрения устройств кэширования и хранения, кластер VMware vSAN представлен дисковыми группами, в каждой из которых есть как минимум одно устройство кэширования и несколько дисков хранения:

Для устройств кэширования на уровне одной дисковой группы установлен лимит в 600 ГБ. Однако это не значит, что нельзя использовать ярус большего объема. Мало того, некоторые пользователи vSAN как раз используют больший объем, так как в этом случае запись происходит во все доступные ячейки SSD (но суммарный объем буфера все равно не превышает лимит), что приводит к меньшему изнашиванию устройств в целом. Например, так происходит в кластере All-flash - там все доступная свободная емкость (но до 600 ГБ) резервируется для кэша.

Надо еще понимать, что если вы поставите очень быстрые устройства кэширования, но небольшого объема - они будут быстро заполняться на пиковой скорости, а потом брать "паузу" на сброс данных на ярус хранения. Таким образом, здесь нужен компромисс между объемом и производительностью кэша.

На базе сказанного выше можно дать следующие рекомендации по оптимизации производительности двухъярусной системы хранения в кластерах VMware vSAN:

• Старайтесь использовать устройства кэширования большего объема, чтобы они могли впитывать большой поток ввода-вывода в течение большего времени. Производительность устройств уже рассматривайте во вторую очередь, только если у вас уж очень большой поток во время всплесков, который нужно обслуживать очень быстро.
• Добавляйте больше дисковых групп, каждую из которых может обслуживать свое устройство кэширования. На уровне дисковой группы установлен лимит в 600 ГБ, но всего на хосте может быть до 3 ТБ буфера, поделенного на 5 дисковых групп.
• Используйте более производительные устройства в ярусе хранения - так сброс данных буфера (destage rate) на них будет происходить быстрее, что приведет к более быстрой готовности оного обслуживать пиковую нагрузку.
• Увеличивайте число устройств хранения в дисковой группе - это увеличит скорость дестейджинга данных на них в параллельном режиме.
• Отслеживайте производительность кластера с помощью vSAN Performance Service, чтобы увидеть моменты, когда ярус кэширования захлебывается по производительности. Это позволит соотнести поведение буфера и профиля нагрузки и принять решения по сайзингу яруса кэширования и яруса хранения.
• Используйте самые последнии версии VMware vSAN. Например, в vSAN 6.7 Update 3 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.

На сайте проекта VMware Labs появилось очередное обновление USB Network Native Driver 1.2 - драйвера для сетевых адаптеров серверов, которые подключаются через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. Напомним, что о версии 1.1 данного драйвера мы писали в июне этого года вот тут.

Обновленный USB Network Native Driver 1.2 теперь дополнительно поддерживает следующие устройства:

• Aquantia Multi-Gig (1G/2.5G/5G) USB network adapter (компания Aquantia - это часть Marvell, кстати это также и производитель адаптеров 10GbE NICs в Mac Mini 2018 и новых iMac Pro).
• Поддержка функции Auto Speed/Connection detection для чипсетов RTL8153/RTL8152.

Таким образом, полный список поддерживаемых теперь устройств выглядит так:

Как пишет Вильям Лам, адаптер  USB-based Multi-Gigabit Network Adapter (QNA-UC5G1T) от QNAP теперь полностью поддерживается (он есть в таблице выше), и он может работать на скоростях 1Gbps, 2.5Gbps и 5Gbps. Но на практике USB 3.1 выдает не больше 3Gbps:

Скачать USB Network Native Driver 1.2 можно по этой ссылке.

На сайте проекта VMware Labs появилась обновленная версия мобильного клиента для управления виртуальной инфраструктурой - VMware vSphere Mobile Client 1.5. Напомним, что о версии 1.3 мобильного клиента мы писали вот тут.

Давайте посмотрим, что нового в vSphere Mobile Client версий 1.4 и 1.5 (кстати, в Changelog версия 1.5 была ошибочно обозначена также как 1.4):

• Теперь поддерживаются прямые соединения к хостам ESXi, а не только через vCenter.
• Хост ESXi можно перевести в режим обслуживания (maintenance mode).
• Новое представление Cluster View, где видны события кластера.
• Появился диалог подтверждения при быстрых операциях с виртуальными машинами.
• Карточка кластера теперь показывает имеющиеся проблемы, статус DRS и HA, а также число событий vMotion.
• Карточка хоста ESXi показывает имеющиеся проблемы, число виртуальных машин, текущий аптайм и статус соединения.
• Выход из деталей ВМ обратно не обновляет страницу.
• Множество исправлений ошибок.

Скачать обновленный vSphere Mobile Client 1.5 можно по этим ссылкам:

• Android (в комбобоксе загрузки просто выберите apk-файл).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.